For more than two decades, the enterprise software industry has operated on a simple, mostly unquestioned premise: writing code is hard, expensive, and scarce, so we should build tools that let people avoid it. Low-code and no-code platforms exist because of that premise. So do BPMN, DMN, CMMN, and XPDL — the alphabet soup of process-modeling standards that promised to let “business users” design workflows by dragging boxes onto a canvas instead of writing software.
Generative AI has quietly broken that premise. Coding is no longer the scarce resource it was. A well-specified intent, handed to a capable agent, now produces real, working, testable code faster than a person can arrange shapes in a palette. That single shift doesn’t just make low-code platforms a little less necessary — it removes the reason they exist.
This is an argument for what should replace them: code-first, spec-driven, agentic development — built on durable, scalable runtimes and observed with the same rigor we apply to every other piece of production infrastructure. And it’s an argument for retiring the standards — BPMN, DMN, CMMN, XPDL — that were never actually delivering on their promises in the first place.
The citizen developer was a workaround, not a vision
The “citizen developer” is one of the more successful pieces of vendor marketing in enterprise software history! The pitch was appealing: business analysts and process owners, who understand the workflow better than anyone, should be able to build and change it themselves — no engineers required. Low-code platforms and visual process notations were built to make that possible.
But look at what actually had to happen to make a citizen developer productive. BPMN diagrams became sprawling, deeply nested graphs that only a specialist could safely modify. DMN decision tables multiplied into their own maintenance burden. CMMN’s case-management flexibility made behavior harder, not easier, to reason about. Popular Process modeling tools have already eliminated support for CMMN! XPDL, sold as a portable interchange format, rarely actually ported a process cleanly from one vendor’s engine to another’s. Every one of these tools, in practice, became its own programming language — just one with worse tooling, worse version control, no real unit testing, and a much smaller pool of people who actually understood it.
The citizen developer was never a natural persona that emerged from how businesses actually work. It was a persona manufactured to justify a category of platform. The tell is that the “no-code” promise almost always broke down the moment a process needed real complexity — at which point organizations hired specialists to write BPMN, which is to say: they hired programmers to write code in a worse programming language than the ones we already had.
GenAI removes the premise
None of this was a moral failing of low-code vendors. Given the constraints of the time, visual modeling was a genuinely reasonable bet on how to make process logic accessible to more people. The problem is that the underlying constraint — coding is scarce and hard to delegate — no longer holds.
A process owner today can describe what they want in plain language and have an agent generate the orchestration logic, the integration code, and the tests, in a real programming language, in minutes. That artifact is versionable in Git, reviewable in a pull request, testable in CI, and debuggable with the same tools every other engineer already uses. It doesn’t require learning a bespoke notation with its own quirks and gateways and token semantics. It requires describing intent clearly — which, it turns out, is a skill business stakeholders already have.
In other words: the accessibility that low-code and BPMN promised is now better delivered by natural language and agents than it ever was by a canvas. The skills gap those tools were built to paper over is closing from the opposite direction. Coding, as a bottleneck, is being commoditized — and everything built on the assumption that it wouldn’t be needs to be reconsidered.
What actually matters now: scalability and durability
Once generating the logic is no longer the hard part, the hard part becomes obvious: making that logic run correctly, for a long time, at scale, in the real world. A process that approves a loan might run for milliseconds. One that manages a supply chain exception might run for weeks, survive multiple deployments, wait on a human who’s on vacation, retry a flaky payment provider, and pick up exactly where it left off after a data center failover.
This was always the actual hard problem in business process automation — not how to draw the diagram, but how to guarantee the process’s state, retries, and progress across failure, time, and scale. BPM engines tried to solve this by wrapping a heavyweight, often proprietary runtime around an XML graph interpreter. It worked, up to a point, but durability was always bolted on top of the notation rather than built as the primitive underneath it.
This is precisely backwards. Durability and scalability should be properties of the execution engine — guaranteed by the runtime, independent of how the logic was authored — not features layered on top of a diagramming standard. A process should survive a crash because the platform underneath it is built for that, not because the vendor’s proprietary engine happened to checkpoint the right XML node. Once you treat durable, scalable execution as the foundation, the question of “how do I express my business logic” becomes secondary — and code, generated and maintained by agents, is a perfectly good answer.
From low-code to Skills-driven, spec-based development
The successor to the low-code palette isn’t a better palette. It’s a library of Skills — composable, versioned, independently testable units of capability that an agent can invoke to accomplish a step in a larger process. Where a BPMN palette gave you a fixed set of generic activity shapes to wire together by hand, a Skills-based approach gives agents a growing, reusable library of real capabilities — each one ordinary code, each one testable in isolation, each one improvable without redesigning the whole process.
Paired with spec-based development, this preserves everything low-code got right about accessibility without inheriting what it got wrong about maintainability. A process owner still describes intent — what should happen, in what order, under what conditions, with what guarantees. But instead of that intent being trapped in a proprietary diagram, it’s expressed as a spec that agents translate into real, versioned code, invoking Skills as building blocks. Engineers stay in the loop where judgment is needed; agents handle the mechanical translation from intent to implementation. The result is something a diagram never gave you: business logic that is simultaneously accessible to describe and rigorous to run.
Observability has to grow up too
Ask anyone who has operated a BPM platform in production what it’s like to debug a stuck process, and you’ll hear the same complaint: the tooling gives you a “cockpit” — a narrow, proprietary window that shows tokens moving through the process diagram, and little else. It’s built for watching one process on one engine. It was never built to answer the questions a modern platform team actually has: how does this process’s latency compare across versions, what’s the blast radius of this dependency’s outage, how does this failure correlate with everything else happening in the system right now.
That cockpit model doesn’t survive contact with a code-first, agentic architecture, and it shouldn’t. Once your processes are real services made of real code and agent-invoked Skills, they deserve the same observability stack as the rest of your production estate: distributed tracing, unified metrics and logs, SLOs, alerting that’s integrated with the tools your SREs already use — not a bespoke console bolted onto a process engine that only your BPM specialists know how to read. Observability should be a property of the platform, not a separate product you buy from the same vendor that sold you the modeling tool.
The standards that won’t survive
It’s worth naming the casualties directly: XPDL, BPMN, DMN, and CMMN. Each was sold on two promises — that they’d make process logic accessible to non-developers, and that they’d make it portable across vendors via an open standard. Neither promise held up well even before GenAI. BPMN 2.0 XML exported from one engine routinely fails to import cleanly into another. DMN tables become their own maintenance liability at scale. CMMN’s flexibility makes behavior harder to predict, not easier. And the notations themselves have a learning curve that, for anyone without prior exposure, is arguably steeper than learning to describe intent in plain language to an agent.
Now consider what’s left standing after GenAI. The accessibility argument is gone — natural language plus agents is more accessible than any of these notations ever were. The portability argument was always weaker in practice than in the spec documents. What remains is a shrinking pool of specialists who know these standards well, maintaining brittle XML graphs that are harder to test, harder to diff, and harder to scale than the code a spec-driven agent would produce in their place. That’s not a foundation to build on. It’s technical debt with a standards body behind it.
The platforms already proving this out
This isn’t a hypothetical future. A new generation of orchestration platforms has already been built around exactly the principles this argument depends on — code as the interface, durability as a runtime guarantee, and observability as a first-class citizen rather than an afterthought.
Temporal, for example, is one of the clearest expressions of this thesis in production today. Workflows and activities are written as ordinary code — Go, Java, Python, TypeScript, .NET, Rust — not XML, not a proprietary DSL, not boxes on a canvas. Durability is a property of the runtime, not the notation: execution state and history are persisted automatically, a workflow resumes exactly where it left off after a crash, a deployment, or a multi-day wait on a human, and retries, timeouts, signals, and versioning are primitives the platform guarantees rather than annotations the process owner has to configure correctly. A long-running, human-in-the-loop process that would sprawl across a dozen BPMN swimlanes becomes a single function a developer can read top to bottom, unit test, and put through a normal code review. It’s not a coincidence that Temporal has become the default landing spot for teams migrating off Camunda, TIBCO, and similar BPM-era engines — it’s the strongest existing evidence that durable execution, not process notation, is the right layer to build on.
This is no longer about asking a business user to drag a box onto a canvas; but treat state, retries, and durability as runtime guarantees rather than modeling features, and is something that has been gaining ground precisely where legacy BPM suites are losing it — among teams that have stopped believing coding is the bottleneck.
A call to rethink
None of this is an argument against modeling business logic carefully, or against giving non-engineers a real say in how processes behave. It’s an argument against the specific tools the industry built to do that — tools whose core justification, the scarcity of coding as a skill, has been removed.
If you’re evaluating your process automation stack today, ask three questions. Is the platform built around a code-first, spec-driven workflow that agents can generate and maintain, using a real language with real version control — the way Temporal, Astronomer, and increasingly Orkes Conductor already do? Is durability and scale a guarantee of the runtime itself, not a feature bolted onto a diagram interpreter? And is observability a first-class, enterprise-grade capability, integrated with the rest of your stack, rather than a narrow cockpit sold alongside the modeling tool?
If the answer to any of those is no, it’s worth asking what you’re actually still getting from BPMN, DMN, CMMN, or XPDL — because the reasons you adopted them in the first place no longer apply, and the market has already started moving on without them.